Self-contained docker build with ARM64 publishing #3962

keynmol · 2025-11-18T14:15:03Z

At the moment, the scala-cli docker image is built using a combination of mill tasks, scripts, and dockerfiles that require externally built binary. What's more, it's only built for x86.

With ARM64 runners on GHA being GA, I propose a simplification - a self-contained multi-stage dockerfile, with a custom Github Workflow that merges the images into a single manifest, meaning that docker will pull the correct image no matter the target platform.

Manifest merging and pushing is a complicated step, and Docker have been amending their docs with the example, which is what this workflow is based on.

I've been using this setup in multiple apps, e.g. Mimalyzer.

There are some aspects of the build I don't really understand – static, mostly static images, customisation for Linux x86, etc.

This proposal attempts to do the simplest possible thing, so that building a docker image is just docker build . -t VirtusLab/scala-cli.

Currently, it only publishes to ghcr.io to test out the workflows without disturbing the main image on docker hub. But additional publishing steps are easily added, of course

keynmol · 2025-11-19T09:40:23Z

Dockerfile

+RUN ./mill -i copyTo --task 'cli[].base-image.nativeImage' --dest "./docker-out/scala-cli" 1>&2
+
+FROM debian:stable-slim
+RUN apt update && apt install build-essential libz-dev clang procps -y


Note that I'm not sure if installing those dependencies in a base image is a good idea, or better left to downstream images. Even though I see the appeal of making native and native-image stuff work out of the box..

Main concern is the size

I mean, we definitely want Scala Native to build nicely with it, so clang is a must.
I'd like to keep them, I think.

Gedochao

@tgodzik @zielinsky can you take a look as well? I think it'd be good to have another pair of eyes on this (or two)

Gedochao · 2025-11-19T12:02:53Z

.github/workflows/publish-docker.yml

+  group: ${{ github.workflow }}-${{ github.ref }}
+  cancel-in-progress: true
+
+# Configures this workflow to run every time a change is pushed to the branch called `release`.


...you mean like, v* tags and main, right?

Gedochao · 2025-11-19T12:03:49Z

.github/workflows/publish-docker.yml

+    strategy:
+      fail-fast: true
+      matrix:
+        os: ["ubuntu-22.04", "ubuntu-22.04-arm"]


Suggested change

os: ["ubuntu-22.04", "ubuntu-22.04-arm"]

os: ["ubuntu-24.04", "ubuntu-24.04-arm"]

we're using 24.04 everywhere in the build, I think

Gedochao · 2025-11-19T12:06:04Z

.github/workflows/publish-docker.yml

+          retention-days: 1
+
+  docker_release_merge:
+    runs-on: ubuntu-22.04


Suggested change

runs-on: ubuntu-22.04

runs-on: ubuntu-24.04

Gedochao · 2025-11-19T12:07:48Z

Dockerfile

+RUN ./mill -i copyTo --task 'cli[].base-image.nativeImage' --dest "./docker-out/scala-cli" 1>&2
+
+FROM debian:stable-slim
+RUN apt update && apt install build-essential libz-dev clang procps -y


I mean, we definitely want Scala Native to build nicely with it, so clang is a must.
I'd like to keep them, I think.

Gedochao · 2025-11-19T12:19:32Z

There are some aspects of the build I don't really understand – static, mostly static images, customisation for Linux x86, etc.

Static and mostly static images are in the understanding of GraalVM, as per this doc: https://www.graalvm.org/21.3/reference-manual/native-image/StaticImages/index.html
The way they're built is based on the mill-native-image plugin: https://github.com/alexarchambault/mill-native-image

(...) customisation for Linux x86 (...)

What particular customisation for Linux x86 did you mean?

(...) etc.

Shoot away, I'll try to answer, or at least direct you in the direction of an answer.

What's there in this area was initially coded by @alexarchambault (who's also the author of mill-native-image). While I've tinkered with this here and there, most of it has been lying untouched for a long, long time, and I'm not all that familiar with it either.

tgodzik

I don't know much about this, I only built basic docker images. Overall look ok as long as it work 😅

zielinsky

A few comments from me 😅

zielinsky · 2025-11-20T22:54:01Z

.github/workflows/publish-docker.yml

+      # This step uses [docker/metadata-action](https://github.com/docker/metadata-action#about) to extract tags and labels that will be applied to the specified image. The `id` "meta" allows the output of this step to be referenced in a subsequent step. The `images` value provides the base name for the tags and labels.
+      - name: Extract metadata (tags, labels) for Docker
+        id: meta
+        uses: docker/metadata-action@9ec57ed1fcdbf14dcef7dfbe97b2010124a938b7


Same situation, a very old version.

zielinsky · 2025-11-20T22:54:30Z

.github/workflows/publish-docker.yml

+      # It uses the `tags` and `labels` parameters to tag and label the image with the output from the "meta" step.
+      - name: Build and push Docker image
+        id: push
+        uses: docker/build-push-action@f2a1d5e99d037542a71f64918e516c093c6f3fc4


Same situation, a very old version.

zielinsky · 2025-11-20T22:55:49Z

.github/workflows/publish-docker.yml

+
+      # This step generates an artifact attestation for the image, which is an unforgeable statement about where and how it was built. It increases supply chain security for people who consume the image. For more information, see "[AUTOTITLE](/actions/security-guides/using-artifact-attestations-to-establish-provenance-for-builds)."
+      - name: Generate artifact attestation
+        uses: actions/attest-build-provenance@v1


The attest-build-provenance documentation says to use version @v3

zielinsky · 2025-11-20T22:58:26Z

.github/workflows/publish-docker.yml

+          username: ${{ github.actor }}
+          password: ${{ secrets.GITHUB_TOKEN }}


Suggested change

username: ${{ github.actor }}

password: ${{ secrets.GITHUB_TOKEN }}

username: ${{ env.REGISTRY_LOGIN }}

password: ${{ env.REGISTRY_PASSWORD }}

zielinsky · 2025-11-20T22:59:27Z

.github/workflows/publish-docker.yml

+          username: ${{ github.actor }}
+          password: ${{ secrets.GITHUB_TOKEN }}


Suggested change

username: ${{ github.actor }}

password: ${{ secrets.GITHUB_TOKEN }}

username: ${{ env.REGISTRY_LOGIN }}

password: ${{ env.REGISTRY_PASSWORD }}

zielinsky · 2025-11-20T23:00:46Z

.github/workflows/publish-docker.yml

+        uses: actions/checkout@v4
+
+      - name: Log in to the Container registry
+        uses: docker/login-action@65b78e6e13532edd9afa3aa52ac7964289d1a9c1


This is a version from two years ago, shouldn't we bump it up to the latest one?

zielinsky · 2025-11-20T23:03:19Z

.github/workflows/publish-docker.yml

+        uses: docker/setup-buildx-action@v2
+
+      - name: Log in to the Container registry
+        uses: docker/login-action@65b78e6e13532edd9afa3aa52ac7964289d1a9c1


keynmol added 3 commits November 18, 2025 13:40

wip

4d9fdec

WIP

b9b37b3

Docker publishing workflow

5a2da94

keynmol commented Nov 19, 2025

View reviewed changes

Gedochao reviewed Nov 19, 2025

View reviewed changes

Gedochao requested review from tgodzik and zielinsky November 19, 2025 12:08

tgodzik reviewed Nov 20, 2025

View reviewed changes

zielinsky reviewed Nov 20, 2025

View reviewed changes

	os: ["ubuntu-22.04", "ubuntu-22.04-arm"]
	os: ["ubuntu-24.04", "ubuntu-24.04-arm"]

		username: ${{ github.actor }}
		password: ${{ secrets.GITHUB_TOKEN }}

Self-contained docker build with ARM64 publishing #3962

Are you sure you want to change the base?

Self-contained docker build with ARM64 publishing #3962

Conversation

keynmol commented Nov 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Gedochao left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Gedochao commented Nov 19, 2025

Uh oh!

tgodzik left a comment

Choose a reason for hiding this comment

Uh oh!

zielinsky left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

keynmol commented Nov 18, 2025 •

edited

Loading